The present invention relates to the field of traffic routing, in particular the routing of packets and the provision of Quality of Service, QoS, for packets transmitted over a computer network.
As the volume of traffic transmitted on packet switched networks has increased, and the types of traffic transmitted over such networks has broadened to include traffic types that rely upon low latency transmission over the network, such as voice or streaming media, it has become increasingly important to enable proactive management of the traffic on the network.
Quality of service models have arisen to enable differentiated handling of different types of network traffic. The integrated services, Intserv, architecture is designed to guarantee a particular quality of service for the transmission of a stream of packets across a network.
Prior to transmission of a stream of packets, Intserv requires that an originating network component reserves resources in each router through which the stream of packets will pass. This resource reservation, usually requested using RSVP (Resource Reservation Protocol), ensures that each router in the path has the necessary resources to guarantee transmission of the packet stream at a particular QoS prior to transmission of the packet stream. However, the IntServ system does not scale easily, since it quickly becomes difficult for the network components to manage the reservations.
An alternative approach is the differentiated services, Diffserv, computer networking architecture enables the network to classify the traffic into one of a specified and predetermined number of traffic classes. A differentiated services, DS, field is populated in each packet transmitted across the network and the field indicates to the network the quality of service, QoS, that is to be provided to that packet in its transmission between network components. The DiffServ model can be used to provide low-latency transmission of critical network traffic, such as streaming packets or voice-over-IP packets, across a network. Packets not marked with a prioritised packet code, such as email and web traffic, can be transmitted when the network components have capacity to do so.
According to one aspect, there is provided a method of managing a plurality of QoS models for traffic flows in a network, the method comprising:
storing the plurality of QoS models;
analysing at least one of the plurality of QoS models to determine whether the at least one QoS model satisfies a suitability test;
selecting one or more QoS model from the plurality of QoS models based on the analysis offering the one or more selected QoS models to a client for use with a traffic flow in the network.
A network implementing flexible and adaptable QoS models can be provided, in particular by developing the DiffServ Classes of Service model into a system of multiple time-variant QoS models that are discovered dynamically and can also include softer policy-related routing options, such as network resilience, energy usage and cost. However, such a system can result in a single network holding a large number of QoS models at a single time. By way of non-limiting example, some of these can be internal and layered over other QoS models. Other models might not be suitable for a given client request if they do not meet the client's mandatory QoS request. Some models might not suit network policy at a given time for a given client. It might therefore be unnecessary or indeed inappropriate to expose all the available QoS options to a client. The present system and method therefore enables filtering to take place in deciding which QoS options should be exposed to a single client request at a specific time. This can be implemented to prune the number of options the client has to evaluate to decide the best QoS option for the given traffic by offering only selected QoS models or options to the client.
Optionally, the method further comprises analysing at least two, optionally each, of the plurality of QoS models to determine whether the at least two, or each, QoS model satisfies the suitability test. While it is desirable in some implementations to offer only a single QoS model to a requesting client, analysis of multiple QoS models by the network can enable the network to offer a plurality of QoS model options to a requesting client.
The method may further include receiving a query from a client requesting reservation of network resources for a traffic flow, preferably wherein the query is received prior to the step of analysing.
The query from the client optionally specifies at least one QoS metric for the traffic flow. The QoS metric may include a QoS Desired, QoS_D object, including parameters such as data rate, bucket size, peak rate, minimum policed unit and maximum packet size. The QoS metric may further include a min_QoS object that specifies minimum thresholds of traffic treatment that the client expects.
Optionally, the analysis is based on the query received from the client, for example based on an identifier of the client or an identifier of the source or destination of the traffic flow. Hence the analysis may be client-dependent and/or traffic-flow dependent which can enable the analysis to take into account factors such as past preferences or behaviour of the client, and expected attributes of the traffic flow as described in more detail below.
Optionally, the analysis is based on the at least one QoS metric specified in the query.
In some embodiments, the analysis is time-dependent or is dependent on conditions in at least a portion of the network. Hence the analysis can take into account the time of day and/or day of the week that the query is received. This can assist for example in predicting expected traffic capacity on the network, or on a portion of the network, at a particular time and can also add to the assessment of the expected characteristics of the traffic flow for which a request has been made, for example a query may correspond to an equivalent query sent by the same client at the same time in the previous week. Furthermore, the analysis can take into account factors such as network load in particular on different routes or different topological areas of the network and avoid further burdening congested network regions.
Optionally, the method further comprises ordering the selected QoS models prior to offering the selected models to the client. Ordering, prioritising or ranking the selected models can provide the network with further influence or control over the QoS model selected by a client following a query. In particular, the client may be configured to consider the models in order and select the first appropriate model offered by the network.
The method may further include receiving a response message from the client to request reservation of network resources based on a QoS model selected from the offered QoS models.
Each QoS model may have a plurality of associated parameters, optionally the parameters comprise at least one of jitter, loss, delay and resilience.
Optionally, the method further comprises deleting QoS models that do not satisfy the suitability test. For example, if a QoS model is not deemed to be suitable over an extended period, such as throughout a period of a week, or is not deemed to be suitable for any one of a plurality of client requests, the QoS model can be deleted from the store or marked as no longer active. This can provide a mechanism to reduce the number of QoS models that the network needs to store to avoid a build-up in number of models over time. However, in an alternative embodiment, a separate process may be used to prune QoS models from the store.
In some embodiments, the analysis is based on at least one of:                a characteristic of the or each QoS model        a characteristic of the client        a characteristic of a query received from the client requesting reservation of network resources for the traffic flow        a characteristic of the network or an operator of the network        
Further details of each of these factors and how they may be applied to influence the analysis is set out below. The skilled person will appreciate that more than one, optionally all, of these characteristics may be taken into account as part of the analysis and that the analysis may take the characteristics into account in any order. In particular, as described in more detail below, the order in which the characteristics are taken into account in the analysis can be varied in order to make the analysis more efficient, for example by excluding from the analysis at an early stage large numbers of QoS models that, for example, will never be appropriate for a particular client.
A plurality of routes is usually associated with each QoS model, wherein each route associated with a QoS model is capable of carrying a traffic flow using QoS parameters corresponding to those of the QoS model. Once a QoS model has been selected, any one of the routes may be used to transmit the traffic flow through the network.
In the methods described above, both QoS models developed based on policy considerations and QoS models developed based on performance considerations can be taken into account.
In one embodiment, the analysis is based on a characteristic of the or each QoS model and the analysis comprises determining a measure of stability of the QoS model over time. Stability may be considered to be a measure of the length of time over which a QoS model is expected to remain within range of its advertised QoS parameters. Alternatively, but equivalently, stability may be considered as a measure of the likelihood or probability of a QoS model straying away from the advertised QoS parameters within a fixed time period.
Optionally, determining a measure of stability comprises: identifying a plurality of routes for traffic flow through the network having parameters with values corresponding with values of parameters associated with the QoS model at a time, t; and determining, for each of the plurality of routes, a duration T over which the values of the parameters for the route are expected to continue to correspond with the values of the parameters associated with the QoS model. With results for multiple routes within the QoS model aggregated, this can provide an indication of the length of time during which the QoS model as a whole will remain stable.
Alternatively, or as an additional measure, determining a measure of stability comprises: identifying a plurality of routes for traffic flow through the network having parameters corresponding to parameters associated with the QoS model at a time, t; and determining a number of routes, n, for which the parameters are expected to correspond with the parameters of the QoS model throughout time t+T. This provides an alternative or additional mechanism for determining a measure of stability of the QoS model as a whole.
Optionally, a parameter associated with the QoS model has a range of values and the corresponding parameter of a route is considered to correspond with the parameter of the QoS model if the value of the route parameter remains within the range of values.
Alternatively, in particular for a different parameter, a parameter associated with the QoS model comprises a parameters each having a value and wherein the corresponding parameter of a route is considered to correspond with the parameter of the QoS model if the value of the parameter of the route remains within 20%, preferably within 10%, of the value of the corresponding parameter in the QoS model. As the skilled person will appreciate, some parameter associated with a QoS model may be assessed against a range of values for that parameter and other parameters may be assessed based on how close they remain to a fixed value.
Values of the parameters associated with the routes for traffic flow through the network may be recalculated periodically. Different routes can then be assigned to different QoS models periodically, based on the recalculation.
Optionally, the analysis is based on characteristics of the or each QoS model and the analysis comprises determining a measure of deviation of the QoS model over time. The deviation of a QoS model may be determined alternatively or additionally to the stability of a QoS model. Deviation provides a measure of how far from QoS parameters a model is likely to stray in a particular time period.
In particular, determining a measure of deviation of the QoS model comprises determining a measure of the extent to which parameters associated with each route for traffic flow through the network deviate from parameters associated with the QoS model within a predetermined time period. The measure of deviation may be presented as an aggregate figure calculated based on the deviation of each QoS parameter. However, the deviation of particular parameters within the QoS model may also be determined and presented separately to the analysis step.
Optionally, the stability or deviation of a QoS model is based on measures of stability or deviation of each of a plurality of routes associated with the QoS model.
In some embodiments, the analysis is based on one or more QoS parameters in a query received from the client, optionally wherein the parameters comprise at least one of jitter, loss, delay and resilience. Parameters received from the client may therefore form the basis of the analysis of the suitability of particular QoS models. In particular, the analysis may include assessing how closely the parameters of each available QoS model match the parameters defined by the client in the query.
Optionally, the analysis is based on characteristics of the client or traffic flow, wherein the characteristics include at least one of: past behaviour of the client, for example the timing and type of past requests; past preferences of the client or of a population of clients connected to the network, for example previous QoS models selected by the client or client population; past impact of traffic from the client on the network, in particular the extent to which previous traffic flows from a particular client have remained within the bounds of QoS parameters selected by the client to handle those traffic flows; the expected traffic type within the traffic flow; the client type.
The characteristics of the client or traffic flow can be determined based on the time of day or the time of week. Hence the analysis may be time-varying.
Optionally, the method further comprises analysing and profiling a client query based on at least one of: a traffic flow source, a traffic flow destination, a traffic flow traffic type, requested QoS parameters in the query, application type for the application originating the traffic flow, time of day, time of week, an indicator of the client type.
Past behaviour of a client can include a measure of the likelihood of deviation of the traffic flow from traffic flow characteristics sent by the client in a query for the traffic flow.
Optionally, the analysis is based on characteristics of the network or an operator of the network and the analysis comprises assessing the one or more QoS models against criteria defined by the network operator.
The criteria defined by the network operator may include one or more of: a cost associated with the QoS model; a maximum threshold on the number of offered models; maximum performance boundaries which may be in place for specific clients; revenue; time of the query; and network load at a particular time or in a particular portion of the network.
According to further aspects, there are provided apparatus, a system, a computer readable medium or computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any method as set out herein. Any feature in one aspect may be applied to other aspects, in any appropriate combination. In particular, method aspects may be applied to apparatus and computer program aspects, and vice versa.
Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.